With an increasing number of services made available to end-users subscribing to fixed or wireless network access, there is a rising demand for making such services easily accessible, not only during established usage but also as an initial introduction to the services.
Rich Communication Services (RCS) is a group of services which relate to a global program that deploys inter-operator services within an industry ecosystem. RCS has been created by GSM Association (GSMA) with a purpose of offering richer communication services supported by a strong ecosystem and a variety of architecture implementation options.
RCE and Voice over Long Term Evolution (VoLTE) share the same IP Multimedia Subsystem (IMS) investment and leverages the same IMS capabilities.
For consumers, RCS combine voice and SMS with instant messaging or chat, live video sharing and file transfer across different types of devices, or user equipments (UE), and networks, and provide main features, such as e.g. an enhanced phonebook, providing service capabilities and enhanced contact information, such as e.g. presence and service discovery; enhanced messaging, which enables a large variety of messaging options, including chat, emoticons, location sharing and file sharing, and enriched calls, which enables multimedia content sharing during a voice call, video call and video sharing.
RCS requires exchanging of service capabilities to be successfully executed between two RCS capable UEs, i.e. that a UE reviles which services it has available to the other UE, prior to establishing of an actual RCS based service between the two UEs.
Section 2.6.2 of RCS 5.1, version 2.0 describes two possible mechanisms for service capabilities exchange, namely SIP OPTIONS and Presence. Even though the standard does not require the service capabilities exchange process to provide any authorization or any privacy management framework, in principle any user can request capabilities associated with another user, being registered to one or more UEs or devices, from any UE or device. When e.g. a service capabilities exchange is executed using the Presence alternative, a privacy framework is made available to the users. Section 2.6.1.3 of RCS 5.1, version 2.0 indicates that when users already have established a social Presence relationship, service capabilities can be requested and acquired via a Presence subscription, but only if the present authorization rules allow that.
Also, nowadays users of Over The Top (OTT) services, such as e.g. Facebook™, Google Hangouts™ or Skype™ are provided with the option of controlling which users can see their service capabilities, and, as a consequence, under such circumstances users must first establish a social relationship before these service capabilities can be exchanged. It is reasonable to expect that also RCS users may want to find corresponding functionality in RCS, i.e. the ability to have control over their service visibility.
A typical scenario, involving two users, communicating via respective UEs may be described as follows, with reference to a simplified signalling scheme illustrated in FIG. 1.
A first user, who is registered with, and capable of communicating via a UE, here referred to as first UE 110a, is an RCS user, i.e. the first user is subscribing to RCS and is using an RCS enabled UE. The first user now wants to communicate with a second user via an IMS network, here represented by IMS core 100, and a second UE 110b. 
The second user is very concerned about his privacy. Therefore he decides to limit the number of users he wants to authorize to contact him via RCS services to his family and a limited number of RCS subscribing friends. Such an authorization procedure implies that the first user is only willing to share associated service capabilities related information with a limited list of RCS users, while remaining RCS users who may try to initiate RCS services with the first user will not succeed. Furthermore, the latter category of users will not even be able to become aware of whether or not the first user is an RCS user. Consequently, the second user connects to the IMS core 100 and configures his privacy settings by provisioning his authorization rules accordingly, as indicated in step 1:1 of FIG. 1. Such a provisioning does not include the first user mentioned above.
Even though the first user is a very good friend of the second user, he is not among the friends authorized by the second user in step 1:1, or in any previous authorization provisioning step. There are a number of reasons why the second user may not be among the authorized RCS users. Let us e.g. assume that the first user has just recently acquired an RCS capable or enabled UE and an RSC subscription of which the second user is not yet aware of, i.e. the second user is unaware of that the first user is a potential RCS counterpart.
When the first user has gone through his imported contacts and wants to discover which ones of his contacts who are RCS users, and thus provide for usage of RCS, he initiates a service capabilities exchange request, requesting for a service capabilities exchange to be executed, as indicated with another step 1:2. Typically, such a request is executed by using a commonly known OPTIONS or Presence mechanism as mentioned above. In the present scenario, it is determined by the IMS core 100 that, since the first user has not been authorized to access the requested service capabilities, such a request will result in a response from the IMS core 100 to the first user, rejecting the request, and instead of exposing the capabilities associated with the second user indicating to the first user that the second user is not found, and, thus, that the first user is not authorized to access the service capabilities associated with the second user, as indicated with a final step 1:3. More specifically, the address book of the first user will typically present the second user as a legacy user, having no RCS capabilities, even though in this case the second user is in fact an RCS enabled user who may even be very keen on communicating via such servicers with the first user. More information on this process can be found in chapter 2.6 of RCS 5.1 Advanced Communications Services and Client Specification, Version 3.0, 25 Sep., 2013.
The described deficiency may also be an obstacle for new users discovery and may contribute to the delay of introduction and spreading of use of this type, as well as similar types of services.